Every manufacturer facing the Digital Product Passport asks the same question at some point: should we build this ourselves or buy a platform? The honest answer is that building is technically feasible and almost never economically sensible. This article lays out the actual cost structure of both paths, the hybrid trap in between, and the four questions that settle the decision in one meeting.
What "building a DPP" actually means
A DPP looks simple from a distance: product data, a public page, a QR code. A weekend project for a good developer, right?
The passport page is maybe 10 percent of the work. The other 90 percent:
- Data pipeline: a sync from your PIM or ERP, attribute mapping, validation logic, error handling for incomplete products
- Standards compliance: data carrier requirements, unique identifiers, interoperability rules defined in the ESPR (Regulation (EU) 2024/1781) and its implementing acts
- Registry connection: the EU's central DPP registry went live on 19 July 2026. Passports must be registered, which means an integration with an EU system, including credential handling and error recovery
- Regulatory tracking: the data requirements per category are set in delegated acts that keep arriving through 2030 under the Commission's ESPR working plan. Every act can change your required fields
- Operations: hosting with public availability guarantees, access management (consumer view vs. authority view), versioning, audit trails
And the ground is still moving. The technical standards for DPP interoperability, data carriers, and registry communication are being developed by CEN and CENELEC in their joint technical committee JTC 24, under a standardization mandate from the Commission. Anyone building in-house today is building against draft standards, and will retrofit when the final versions land. A platform absorbs that retrofit for all customers at once.
The real cost of building
From projects we have seen and been called into, an in-house DPP build for a mid-sized manufacturer lands roughly here:
| Cost block | Typical range |
|---|---|
| Initial development (pipeline, passport, QR, validation) | 30,000 to 50,000 euros |
| Registry integration and standards conformance | 10,000 to 25,000 euros |
| Ongoing maintenance and regulatory updates | 0.25 to 0.5 developer FTE, so 20,000 to 45,000 euros per year |
| Time to first compliant passport | 4 to 8 months |
The maintenance line is the one that gets underestimated. A delegated act lands, your required fields change, and the developer who built the system has moved to another project. That is not a hypothetical, it is the standard failure mode of internal compliance tooling.
There is also a cost line that never appears in the project budget: opportunity cost. Four to eight months of build time is four to eight months in which your competitors' QR codes are already collecting warranty registrations and routing spare parts orders. For the categories with real deadlines, it is also four to eight months carved out of a transition window you do not control.
The cost of buying
A SaaS platform spreads the standards work, registry integration, and regulatory tracking across all customers. With dpp.cloud the numbers look like this: Growth at 10,500 euros per year, Professional at 17,500 euros per year, flat, with no per-SKU fees. Implementation with an existing PIM takes two to three weeks, because your product data gets mapped instead of re-entered. How that works is documented in creating a DPP from PIM data.
Over three years, the comparison for a typical mid-market manufacturer:
| Build | Buy (dpp.cloud Growth) | |
|---|---|---|
| Year 1 | 50,000 to 90,000 euros | 10,500 euros |
| Years 2 and 3 | 40,000 to 90,000 euros | 21,000 euros |
| Time to live | 4 to 8 months | 2 to 3 weeks |
| Regulatory updates | Your team | Included |
| Standards retrofit (CEN/CENELEC) | Your team | Included |
When building actually makes sense
There are cases where an in-house build is defensible. All three of these should be true:
- You have a permanent in-house platform team, and product data infrastructure is already their job
- The DPP is core to your product experience, not a compliance requirement, so you need control down to the last pixel and field
- Your volume is large enough that per-year license costs of any vendor would exceed a full-time engineering team
That describes a handful of very large enterprises. If one of the three is false, the math tips toward buying, and it usually tips hard.
The middle paths, and why they cost the most
Two hybrid routes deserve a warning label.
The consultant-built custom solution combines the downsides of both main paths: you pay build-level costs (often six figures), you wait build-level timelines, and at the end you own bespoke software that only the consultancy understands. Maintenance becomes a recurring negotiation. We compared this path against SaaS platforms in detail in the DPP software buyer's guide.
The "temporary solution" trap is subtler. A team builds a quick static page per product, "just for now, until the requirements are final." Eighteen months later that stopgap has QR codes printed on 200,000 labels pointing at URLs the temporary system controls, and the migration to a real platform now includes a label transition project. If you build something temporary, at minimum route the QR codes through a redirect layer you control. Better: do not print codes that point at throwaway infrastructure.
How to decide in one meeting
Put these four questions on a whiteboard:
- Do we have a team that can own this system for the next eight years, through every delegated act and standards revision?
- Is our product data already structured in a PIM or ERP we can map from?
- What does one month of delay cost us in the category timeline we are on? Check the DPP timeline for your category
- Do we want the passport to do more than comply, for example carry service, spare parts, or resale workflows?
If question 1 gets an honest no, the decision is made. If question 4 gets a yes, look at platforms that treat the passport as customer infrastructure rather than a static data sheet. That distinction is what we built dpp.cloud around, and why every passport can carry a service layer on top of the compliance data.
If you buy: the six questions for every vendor
The buy decision has its own failure modes, most of them discoverable in the first call:
- Can we keep our PIM as the single source of truth, or do you require data import into your system?
- Is pricing flat, or does it scale per SKU, per scan, or per data point? (Per-unit pricing looks small and compounds badly)
- Can you generate passports at item level, and what does switching granularity later involve?
- Who tracks delegated acts and standards changes, and are those updates included in the license?
- What happens to our passports and QR codes if we leave? (URL ownership and export terms, in writing)
- Show us a reference customer who went live within the timeline you just quoted
Next step
If you are running this evaluation right now, book a 30-minute strategy session. We will walk through your data landscape and give you the numbers for your specific setup, including an honest assessment of whether building makes sense in your case.
.jpeg)



%201.png)
